Get in touch
The VMware Event Broker Appliance team welcomes contributions from the community and this page presents the guidelines for contributing to VMware Event Broker Appliance.
Contributing
Following the guidelines helps to make the contribution process easy, collaborative, and productive.
Before you start working with the VMware Event Broker Appliance, please read our Developer Certificate of Origin. All contributions to this repository must be signed as described on that page. Your signature certifies that you wrote the patch or have the right to pass it on as an open-source patch.
This is a rough outline of what a contributor’s workflow looks like:
- Create an issue describing the feature/fix.
- Create a topic branch from where you want to base your work.
- Make commits of logical units.
- Make sure your commit messages are in the proper format (see below).
- Push your changes to a topic branch in your fork of the repository.
- Submit a pull request to
vmware-samples/vcenter-event-broker-appliance.
See below for details on commit best practices
and supported prefixes, e.g. fix: <message>.
Note: If you are new to Git(hub) check out Git rebase, squash…oh my! for more details on how to successfully contribute to an open source project.
Submitting Bug Reports and Feature Requests
Please submit bug reports and feature requests by using our GitHub Issues page.
Before you submit a bug report about the code in the repository, please check the Issues page to see whether someone has already reported the problem. In the bug report, be as specific as possible about the error and the conditions under which it occurred. On what version and build did it occur? What are the steps to reproduce the bug?
Feature requests should fall within the scope of the project.
Pull Requests
Before submitting a pull request, please make sure that your change satisfies the following requirements:
- The change is signed as described by the Developer Certificate of Origin doc.
- The change is clearly documented and follows Git commit best practices (see below)
Format of the Commit Message
We follow the conventions described in How to Write a Git Commit Message.
Be sure to include any related GitHub issue references in the commit message,
e.g. Closes: #<number>.
The CHANGELOG.md and release page use commit message prefixes for grouping
and highlighting. A commit message that starts with [prefix:] will place this
commit under the respective section in the CHANGELOG.
The following example creates a commit referencing the issue: 1234 and puts
the commit message in the Feature CHANGELOG section:
git commit -s -m "feat: Add Slack Example" -m "Closes: #1234"
Currently the following prefixes are used:
fix:- Use for bug fixesfeat:- A new featurechore:- Use for repository related activitiesdocs:- Use for changes to the documentation
If your contribution falls into multiple categories, e.g. feat and fix it is
recommended to break up your commits using distinct prefixes.
Contributions to the Appliance
- See the Build Appliance document here
- See the Build Event Router document here
- Requestor must verify that the VMware Event Broker Appliance can be built and deployed.
Contributions to the Functions
- See the Build Functions document here
- PR should contain information on how the function was tested (environment, version etc)
- PR should contain a titled readme and the title is listed in the Functions page
Contributions to the Website
- See the Build Website document here
- Requestor must verify that the website change was built and tested locally
Get started quickly with your contributions with our getting started guide
Join the movement
VMware Event Broker Appliance is released as open source software and provides community support through our GitHub project page. If you encounter an issue or have a question, feel free to reach out on the GitHub issues page for VMware Event Broker Appliance.
Our team welcomes contributions from the community!
